Many programs are designed to be executed synchronously on a computer employing a blocking paradigm. Referring to FIG. 1, a block diagram 100 illustrating the prior art flow of such a program is shown. The procedure begins at block 110 and starts processing at block 112. Every time procedure logic at block 112 requires a resource allocation or makes a call to an external function at block 116, the program must provide a request to the operating system or other external entity. Upon submitting a request to the operating system or other external entity, several pieces of data are pushed onto a stack such as the address of the program being executed, the program counter identifying the specific instruction within the program to be executed upon return, and any variables related to the program.
After submitting the request, control is transferred to the operating system or other external entity and the requesting program procedure logic must wait until the operating system allocates the requested resource or the other external entity completes processing at block 116. Control is returned to the program procedure logic block 112 upon completion of the request at which point the stack is unwound and the program continues processing from the point at which the request was submitted. Control is then passed to procedure logic at block 118, where eventually an additional call may be made to an external function at block 122. Again, the procedure logic at block 118 must wait until the external function at block 122 completes its request and passes control back to the procedure logic at block 118. The stack is unwound and the program continues processing from the point at which the request was submitted. Control is then passed to procedure logic 124 and, upon completion of its processing, the procedure ends at block 126.
When employing the blocking paradigm, modules of the program cannot be replaced online during execution of the program. Such online module replacement would likely result in outdated or inaccurate data being pulled off the stack upon completion of a request, as the address of the program and its internal functions may have been altered by any online module replacement. In addition, replacing the module could change all of the internal addresses for the code to the extent that there may not be any code at the address that the processor returns to. Even if there is code at the address that the processor returns to, it is unlikely that the code located in the original address performs the original functions.
As an alternative to the blocking paradigm, asynchronous coding systems have emerged in operating system design and implementation. Asynchronous coding systems can reduce blocking due to resource contention and have the potential to enhance modularity and fault isolation to increase system robustness.
One such asynchronous coding system is employed by the Uniform Driver Interface (“UDI”) and enables online module replacement that is not available using a blocking or synchronous coding method. The block diagram of FIG. 2 illustrates the basic structure of a function employing the UDI paradigm. According to this paradigm, the functionality of the prior procedure 200 is distributed across several discrete procedures, procedure 201, procedure 202 and procedure 203. Every procedure making up the function, except for the final procedure 203, concludes with a request for external resources. Further, every procedure making up the function, except for the first procedure 201, acts as a reply handler for the previous procedure. In practice, each procedure of the function is executed up to a point where additional resources are requested. The operating system or other external function services the request, and upon completing the request and, directs control to the next procedure of the function which continues processing where the previous procedure left off.
For example, procedure 201 begins at block 210. At block 212, the procedure logic begins to process and continues processing until the procedure initiates a call to an external function at block 218. When the procedure logic initiates a call to an external function at block 218, procedure 201 ends immediately at block 216. At block 218, the operating system or other external function services the request and the external function is completed. Control is passed to procedure 202 and procedure 202 acts as a handler for the response to the request from procedure 201. Procedure 202 begins at block 220. Control is passed to block 222 and the procedure logic processes until the procedure initiates a call to an external function at block 228. After the procedure logic initiates a call to the external function at block 228, procedure 202 ends immediately at block 226. The operating system services the request and the external function is completed at block 228. Control is passed to procedure 203. Procedure 203 handles the response to the request from procedure 202 and begins at block 230. The procedure logic continues processing at block 232 until it completes and ends at block 230.
While the UDI paradigm improves on the blocking paradigm by enabling online module replacement, it also presents several disadvantages. First, by using a separate reply-handling routine for each external request or call, the namespace, or set of names, of any compilation system may become over-populated and unmanageable. Second, the use of separate reply-handling routines makes it difficult to map logic between the asynchronous code and any original synchronous code that may have been converted to the asynchronous architecture. Third, some looping constructs are difficult to convert from a synchronous coding scheme to the UDI paradigm.